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PATENT 

Attorney Docket No.: 020375-004900US 
SYSTEM AND METHOD FOR MANAGING ACCOUNTS 

BACKGROUND OF THE INVENTION 
[01] The present invention relates to managing accounts at banks, retail establishments and 
5 other commercial and non-commercial institutions, and more particularly to a system and 
method for managing transactions in connection with such accounts. 

[02] Systems for managing credit card and other financial accounts are in widespread use. 
These systems have become sophisticated and complex, particularly as consumers become 
more comfortable with on-line transactions and increase their use of credit cards. Customers 
10 now use credit cards, debit cards and similar devices to make purchases, obtain cash 
p advances, check account balances and move cash between accounts. Transactions are 

ssse. 

% conducted at point-of-sale terminals in retail stores, at automated teller machines, and over 
H; the Internet using personal computers. Many consumers have established multiple accounts, 
[l and in some cases family members each have credit cards and together may be using one or 
f! 5 more of those accounts. 

D [03] One result of the proliferation of credit cards has been the cost, burden and 
S inconvenience of dealing with lost or stolen cards. If several family members are using one 
}1! account, and one loses his or her card, the account is usually closed (to prevent unauthorized 
fti use) and a new account opened with a new card for each family member. The institution 
20 issuing the new card has to change its systems to accommodate the new account, and often 
the cardholders must wait several weeks or more before being able to use the new account. 
[04] Also, banks and other institutions want to target customers for special financial 
services (or other marketing programs) depending, for example, on the extent of use of a 
credit card. A customer that makes frequent use of credit cards may be a candidate for other 
25 financial services offered by the bank. As another example, a customer that uses a credit card 
to purchase certain types of products may be a good prospect for marketing related products. 
As a result, banks and other institutions will track patterns of credit card, debit card and ATM 
card use by cardholders. This becomes difficult, however, if there are several different 
cardholders using the same account. 

30 

BRIEF SUMMARY OF THE INVENTION 
[05] There is provided, in accordance with the present invention, a system and method for 
managing accounts, such as credit card accounts, wherein more than one customer may be 



associated with each account, and wherein each customer has a role relating to such account. 
The customer may conduct a transaction for an account by using a presentation instrument 
(e.g., credit card) issued to that customer. The system includes a database for storing a 
customer ID associated with each customer, an account ID associated with each account, and 
5 a presentation ID associated with each presentation instrument, with the database structured 
for relating each presentation ID to a specific customer and to an account used by that 
specific customer. The system further includes a database management system for managing 
the data stored in the database. 

[06] When a transaction is conducted, transaction data (i.e., data defining the nature of the 
10 transaction, such as the amount and location of the transaction) is posted to an account in 
K response to receiving a presentation ID with such transaction data. The presentation ID is 
5 used by the data management system to access the account and thereby reflect that the 
M transaction has been conducted by the specific customer for that account. 

[07] In one embodiment of the invention, the presentation instruments are credit cards and 
W the accounts are credit card accounts. Multiple cards for the same account may be issued to 

si 

D different cardholders, and the cardholders may have different roles. One cardholder may 
fi have the primary cardholder role and thus have primary financial responsibility for the 
U] account. Other cardholders have secondary or other roles. The database stores data 
Sj indicating the role of each cardholder, and transactions can be tracked for the account as a 
20 whole (using the account ID) and also tracked separately for each cardholder (using the 
customer ID assigned to that cardholder). 

[08] In another embodiment of the invention, if a card is lost or stolen and thereby deemed 
not useable, a security suspense record is stored in the database at the account ID associated 
with the lost or stolen credit card. If a transaction is attempted using that presentation ID, the 
25 security suspense record is retrieved (rather than a valid account ID) and the system 
invalidates the transaction. 

[09] A more complete understanding of the present invention may be derived by referring 
to the detailed description of the invention and to the claims, when considered in connection 
with the Figures. 
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BRIEF DESCRIPTION OF THE DRAWINGS 
[10] In the Figures, similar components and/or features may have the same reference label. 
Further, various components of the same type may be distinguished by following the 
reference label with a second label that distinguishes among the similar components. If only 



2 



the first reference label is used in the specification, the description is applicable to any one of 
the similar components having the same first reference label irrespective of the second 
reference label. 

[11] Fig. 1 is a general block diagram showing a system for managing accounts in 
5 accordance with one embodiment of the present invention. 

[12] Fig. 2 is a diagram illustrating an embodiment of the present invention where there 
are two credit card accounts and where multiple cardholders are using one of those accounts. 
[13] Fig. 3 illustrates a table in the database of Fig. 1 . 

[14] Fig. 4 is a flow diagram illustrating the operation of the database management system 
10 in Fig. 1 , when a cardholder conducts a transaction. 

p DETAILED DESCRIPTION OF THE INVENTION 

ft [15] Referring now to Fig. 1, an account management network 100 in accordance with one 

embodiment of the present invention is illustrated. The network 100 manages credit card 
U accounts and has a plurality of terminals 1 1 0 (1 1 0a through 1 1 On), a central database 
U management system (DBMS) 120 and a database 130. The terminals 1 10 are used to access 
W data in the database 130 via the DBMS 120. The terminals 1 10 may be point-of-sale 
S terminals at remote retail establishments, where credit card information is read or entered, 
3 along with retail transaction data (e.g., the amount of a purchase, as well as the name of the 
20 retail establishment, date, product and other useful information). Such data can be 

conventionally collected, either by electronically reading data from magnetic strips on credit 

cards and from product UPC (uniform product code) labels, or by being manually entered by 

a clerk at a terminal keyboard. 

[16] The terminals 1 10 may also include internal workstations at a bank or other central 
25 location where the credit card accounts are managed. Those workstations would be used by 
employees to enter, collect, retrieve or display data in connection with setting up credit card 
accounts, answering customer telephone inquiries, and performing other normal financial or 
business functions required for operating the credit card management network 100. 
[17] The DBMS 120 can be a relational database management system that permits data in 
30 the database 130 to be created, maintained, manipulated and retrieved. The database 130 is 
likewise relational and, as conventional, stores data in tables, with the DBMS 120 using, for 
example, a structured query language (SQL) in order to maintain and operate the database. 
While the DBMS 120 and database 130 are relational in the described embodiment, those 
skilled in the art will appreciate that there are many types of databases (e.g., sequential flat 
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files, hierarchical, object oriented, etc.) that can be used within the scope of the present 
invention. 

[18] The network 100 as thus far described can be implemented using known architectures 
and systems. In addition, a network that has the underlying architecture and systems for 
5 implementing the present invention can be found in co-pending provisional U.S. Patent 

Application Serial No. , for METHOD AND SYSTEM FOR 

PROCESSING CREDIT CARD RELATED TRANSACTIONS filed on March 4, 2002, by 
Peter M. Zelechoski, Rex Johnson, Richard McKie, Tom Lima, Steve Joyce, Kent Parkinson, 
Norman T. Davis, Tom Emery, Douglas E. Johnson and Nabil Abu El Ata, and owned in 
l r jQ common with the present application (Townsend & Townsend & Crew Docket No. 020375- 
S 000400US), such co-pending application being hereby incorporated by reference. 
J3 [19] In the database 1 30, there is illustrated (Fig. 1) in simplified form the general content 
S of one database table 132 used for purposes of accessing credit card accounts. The database 
: J ] table 132 has three fields (columns) illustrated, namely, a customer ID field 134, an account 
15 ID field 136, and a presentation (presentation instrument or credit card) ID field 138. Thus, 
j for each customer (implemented as a row in the table 1 32), the database maintains a unique 
H and permanent customer ID, the account ID (credit card account number) for each account of 
□ that customer, and the presentation ID (card number) for the card that the customer uses to 
' y access the account. Although not shown in Fig. 1 , the customer may have more than one 
20 account (and hence have more than one account ID and more than one presentation ID) 
associated with the customer ID. 

[20] For reasons which will become apparent later, the customer ID is "permanent", i.e., it 
is not normally changed (at least during the time that the customer continues to have a 
relationship with the card-issuing organization), even if the customer opens a new account, or 

25 has credit cards lost or stolen. However, each account ID and presentation ID may change, 
and new account IDs and presentation IDs may be added to the table, depending on the needs 
or circumstances of the customer. Because of the permanent customer ID, personal 
information pertaining to that customer that is stored in the database 130 (e.g., addresses, 
phone numbers, birth date, social security number, etc.) can be associated with the customer 

30 ID (and thus maintained for that customer) even as account IDs and presentation IDs change. 
[21] The general operation of the network 100 will now be briefly described. If a 
cardholder is at a retail establishment making a purchase, a credit card is presented to a clerk 
and the credit card number (presentation ID) and transaction data for the purchase are entered 
at one of the terminals 1 10 and transmitted to the DBMS 120. In order to make sure the 
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transaction data is posted to the appropriate account, the presentation ID is used to retrieve 
the account ID associated with that presentation ID. Once the account ID is identified, the 
transaction data is stored in the database along with any previously stored transaction data 
pertaining to that account. The account (and collected transaction data) can be periodically 
5 accessed for normal business purposes, for example, to print monthly statements, to 
determine if credit limits have been exceeded, to check for account activity as part of a 
separate marketing program, as well as many other activities of the bank or card issuer. 
[22] As mentioned earlier, in one embodiment the presentation ID will be unique to the 
cardholder. That is, if there are multiple cardholders for one account, each cardholder will 
10 have a different presentation ID even though transactions are all posted against the same 
K account. This permits the card issuer to separately track (if desired) transaction data for each 
p cardholder, for example, when the primary cardholder has established separate credit limits 
nfl for each of the other cardholders. This feature is implemented by assigning a "role" to each 
*\ cardholder. The roles may be relatively simple, such as "primary'' and "secondary". The 
1 5 primary cardholder would have primary financial responsibility for the account (monthly 
[y statements would be addressed to the primary cardholder), and might have the exclusive 
~1 authority to request changes (such as to mailing addresses and to credit limits), close the 
□ account, establish additional cardholders, etc. The secondary cardholder would be able to 

access the account and charge purchases, but not be able to make any changes to the account. 
20 Further, there optionally may be other roles as well, such as might exist for an account where 
children have been issued cards. In such a situation, the "other" role might have significantly 
lower credit limits (as perhaps established by the card issuer), have restrictions on the types 
of products that could be purchased with the card, and have other restrictions appropriate for 
a more limited use of the account. The customer ID and the presentation ID stored in the 
25 database 130 permit the roles for cardholders to be defined not only for each account, but also 
for all accounts for which a card has been issued to one customer. 

[23] The relationships and use of customer IDs, account IDs, presentation IDs and roles 
that multiple cardholders or customers may have in connection with an account, is better 
understood by referring to Fig. 2. 
30 [24] In Fig. 2 there are illustrated four customers 210a, 210b, 210c and 210d. Each 
customer has an assigned customer ID in the database 130. There are also illustrated two 
accounts 220a and 220b, each with an assigned account ID. In the arrangement of Fig. 2, 
customer 210a ("Sam") and customer 210b ("Sue") each have a primary role in connection 
with one of the accounts. In particular, Sam has the primary role for account 220a and Sue 
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has the primary role for account 220b. In addition, Sam has a secondary role for the account 
210b. However, Sam is the only cardholder for account 210a, and thus there are no other 
roles for that account. 

[25] In the example in Fig. 2, the two other customers 210c and 210d ("John" and "Amy", 
5 respectively) are children of Sam and Sue, they are only cardholders for account 220b, and 
thus their roles are "other" and can be much more restricted. As mentioned earlier, this role 
could be restricted (depending on parameters established either by the card issuer or by the 
primary cardholder) as to credit limits, types of purchases, and in other ways appropriate for 
children. 

10 [26] There are five credit cards (presentation instruments) 230a, 230b, 230c, 230d, and 

230e associated with the accounts in Fig. 2, with each card having a unique presentation ID 
D (card number) appearing on the card. Since John is the only cardholder for account 220a, 
;T there is only one card 230a for that account. That card is issued to John as the primary (and 
only) cardholder. As to account 220b, there are four cards issued — card 230b to Sue as the 

u § 

jkS primary cardholder, card 230c to John as the secondary cardholder, card 230d to John, and 
Pi card 23 Oe to Amy. 

W [27] As evident from Fig. 2, when any one of the cards 230 is presented for conducting a 
If] transaction, and the presentation ID associated with that card is provided to the DBMS 120 in 
!Tj Fig. 1, the identity of the account, the identity of the customer, and the role of that customer 
20 on the account, can all be determined by accessing the database 130. 

[28] This may be better understood by referring to Fig. 3, where a table 3 1 0 in the database 
130 is illustrated. This particular table arranges the fields (columns) so that for each 
customer ID there is associated (or related) personal data for that customer, such as name of 
the cardholder (Name), social security number (SSN), telephone number (TEL), date of birth 
25 (DOB), account IDs (Acctl ID, Acct2 ID), the Role the customer has for each account (P- 
primary, S-secondary or O-other), and the presentation ID (PI ID1, PI ID2) that has been 
assigned to each card used by that customer. As can be seen, Sam has two presentation IDs 
(since he is a cardholder for two different accounts), and Sue and John each have one 
presentation ID. For reasons to be described shortly, Amy has two presentation IDs, but only 
30 one is valid for conducting transactions on the one account for which she is a cardholder. 
[29] It should be apparent that database table 310 is only one of many tables that might 
reside in the database 130. This particular database is used to retrieve account ID, customer 
ID, role information, and other personal data pertaining to any presentation ID, as may be 
needed to determine parameters or restrictions that may apply to the cardholder in accessing 
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the account, or to enable the DBMS 120 to post transactions to the account. Other tables that 
might reside in the database could include, for example, tables for storing transactions 
associated with each account ID or each customer ID, for storing credit limits for each 
cardholder and account, for storing mailing addresses, and so forth. The numbers and nature 
5 of those tables will depend on the needs of the card issuer and its customer. 

[30] In the table of Fig, 3, once a customer (and the account) has been identified and 
retrieved, the DBMS 120 may be used to post transaction data to the account, as well as to the 
specific cardholder using that account. 

[31] This last mentioned feature would be useful when the card issuer wants to track 
10 transaction activity by customer, if there are multiple customers (cardholders) using a single 

[I account. For example, a bank (such as the card issuer) may want to know when non-primary 

D 

D cardholders (e.g., John or Amy) are using their cards with such frequency that perhaps they 

u should be contacted with a view of having their own separate accounts. As another example, 

ft; individual transactions by a customer can be tracked to identify purchases of particular types 

M> of products from particular kinds of retail establishments. If Sue's purchases are tracked and 

s 

□ she is found to frequently purchase luxury products (even though others on the same account 
S are not buying those kinds of products), she can be targeted for special services offered by the 
IH bank for customers having higher cash needs, or even targeted for specialty luxury products 
5] offered by an affiliated retail establishment These, of course, are only a few of many 
20 possible purposes for tracking the transactions of individual cardholders on a multi- 
cardholder account. 

[32] As mentioned earlier in connection with Fig. 3, the customer identified as "Amy" is 
shown to have two presentation IDs, even though she has access to only one account. The 
account for which she has access is shown under the field "Account2 ID", and when she 

25 presents her card having the associated presentation ID (seen under the field PI ID2), she is 
given authorization to conduct transactions against that account. However, in this example, 
Amy has previously lost her card for that account. In order to prevent unauthorized access to 
that same account, a security suspense record is stored in the database 310. 
[33] The suspense security record is a string of recognizable characters (in this case the 

30 characters "999999"). When a specific customer's card is lost, stolen or otherwise determined 
to be unusable, the security suspense record is inserted into the account ID field of that 
account for that customer. In this case, the record is inserted as the last six digits of the 
account ID under the field Accountl ID. The presentation ID for that card (appearing in the 
field PI ID1) becomes invalid and a new card for the same account is issued, with the account 
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number now appearing in the field Account2 ID, and with the presentation ID (card number) 
for the new card appearing in the field PI ID2. 

[34] If the unusable card should be presented for conducting a transaction, the presentation 
ID for that card is provided to the data base and the returned account ID includes the 
5 suspense record "999999". The DBMS can be programmed to instruct the terminal providing 
the invalid card number that the attempted transaction is invalid. Of course, depending on the 
circumstances and the parameters of the card issuer and the retail establishment involved, 
other messages can be transmitted to the terminal involved in the transaction (such as 
"contact a manager" or "contact security personnel" at the retail establishment). 
10 [35] It should be noted that even though a card has been rendered unusable in the case of 

Amy, the other cardholders are not affected. The account remains open, and the presentation 
D IDs associated with that account for the other cardholders may continue to be used. The 
2 impact is limited to the particular card (and presentation ID) of only one customer, and that 

XSSI 

rf j customer only needs to have a new card (with a new presentation ID) issued. 

pjj5 [36] While in the embodiment of Fig. 3 the account ID is different than each presentation 

h. ID, they could in fact be the same for one or more of the cards (for example, when a customer 

■T.'.-S? 

iff prefers to have an account ID and a presentation ID that are the same). However, if there is 
Lf] more than one cardholder for that account, and if any one of the cards is rendered unusable 
m ( e -g-> l° st or stolen), then a different presentation ID (and card) has to be substituted for all 
20 the cards in order to prevent unauthorized use of the account. Of course, this may be of little 
concern if there is only one cardholder for the account. Further, as long as a new presentation 
ID is issued to each cardholder, the original account ID can continue to be used within the 
system for identifying the account (i.e., the account does not need to be closed as long as the 
presentation ID or IDs that were the same as the account ID are changed to a different 
25 number). 

[37] Also, while the table 310 in Fig. 3 is shown as having fields for only two accounts 
(two account IDs and two presentation IDs) relating to each customer ID, there could be any 
number of such accounts, depending on the needs of the card issuer and its customers. 
[38] Fig. 4 is a flow diagram illustrating one embodiment of a process that may be used for 
30 implementing various aspects of the invention described earlier in connection with Figs. 1, 2 
and 3. 

[39] In Fig, 4, when a transaction is initiated, one of the terminals 110 provides a 
presentation (presentation instrument or credit card) ID (PI ID) and transaction data to the 
DBMS 120 (step 410). The DBMS determines if the PI ID is valid (step 412), such as by 
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determining whether a security suspense record has been inserted into the associated account 
ID. If the PI ID is not valid, notification of the invalid PI ID (step 414) is provided, for 
example, to the terminal 110, and the transaction is terminated. 

[40] If the PI ID is valid, then the DBMS determines the account ID and customer ID from 
5 its query of the database 130 (step 416), and determines if the transaction is within the credit 
limit established for the account, i.e., the credit limit established for all transactions from all 
cardholders using the account (step 418). If within the account credit limit, the transaction is 
posted to the account (step 420). If not within the account credit limit, the terminal 1 10 is 
notified that the transaction is not valid (step 422), and the transaction is terminated. 
10 [41] Once the transaction is posted to the account, the DBMS determines whether the 
HJ specific customer/cardholder using the account is to have his/her transactions separately 
O tracked (step 424), and if this is to be done, then a determination is made (if the card issuer 
J™ has optionally prepared the DBMS) whether the transaction is within limits or criteria 
5 established for that customer (step 426). If not within those limits, the terminal 1 10 is 
jjj> notified that the transaction is invalid (step 428) and the transaction is terminated. If the 
r-i transaction is within the limits, it is posted or stored in the database (and related to the 

customer ID) so that it can be collected or tracked for that particular customer (step 430). 
m Once this is done, the transaction is complete. Also, if the transaction is not to be tracked for 
51 the customer, at step 424, the transaction is complete (without going through steps 426, 428 
20 or 430). 

[42] It can be seen from the preceding discussion that the present invention provides a 
novel method and system for providing and maintaining account, customer, role and 
presentation instrument identifiers in an account management network or system. While 
detailed descriptions of presently preferred embodiments of the invention have been given 

25 above, various alternatives, modifications, and equivalents will be apparent to those skilled in 
the art without varying from the spirit of the invention. As one example of equivalents, the 
presentation instrument may be an instrument other than a credit card, and in fact could be 
any card or instrument (e.g., debit card, ATM card, customer ID card) that is used to conduct 
a financial or other transaction, either in person or on-line. Furthermore, the presentation 

30 instrument need not be a tangible instrument at all, but could be simply an identifier or 

password (e.g., string of characters) that a customer has memorized and that can be provided 
whenever a transaction is to be conducted. 

[43] Therefore, the above description should not be taken as limiting the scope of the 
invention, which is defined by the appended claims. 
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